This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
HTTP adaptive technologies are pushed by various stakeholders to allow provision of over the top audiovisual delivery in the Internet. Such technologies allow a client terminal to receive video in the form of small successive segments (a few seconds long), so called chunk. Each segment is requested through the HTTP protocol and may exist in different variants (so called representations), allowing the client terminal to choose at any time an appropriate bit rate matching the network and device constraints.
Among the HTTP adaptive streaming (HAS) protocols which are already used, the most famous are the HTTP Live Streaming (HLS) from Apple, the Silverlight Smooth Streaming (SSS) from Microsoft, the Adobe Dynamic Streaming (ADS) from Adobe and the Dynamic Adaptive Streaming over HTTP (DASH) developed by 3GPP within the SA4 group. These HTTP adaptive streaming existing techniques vary in the manifest file format, said manifest providing meta-data to describe the content options (bit rate, image dimensions, frame rate . . . ), the organization of the available representations of the content in segments, in the codecs supported, and in the content protection technologies.
In particular, when a client terminal wants to play an audio/video content, it first has to get such a manifest describing how this specific content can be obtained. This is done through HTTP by getting some ‘file’ from an URL. This manifest file lists the available representations of the content (in terms of bit rate and other properties) and, for each representation, the URLs that allow loading the content chunks for each time slice. For Video on Demand (VoD), the entire description of the A/V content is provided, while for live content (e.g. TV content), the description covers only a short period of time and needs to be reloaded periodically to discover the new items when time passes.
Depending on its capabilities and the knowledge it has from the networking environment, the client terminal selects one representation (e.g. based on its bit rate) and loads the first chunk(s) of content. It buffers a few chunks to be able to cope with network impediments. Then, the A/V content is played from each received chunks one after the other. At the same time, the client terminal measures the reception rate and may decide to select a higher or a lower bit rate. In such case, it just requests the next chunk(s) from another representation. Every HTTP streaming technique is such that it is possible for the client terminal to keep a continuous playing while going from a chunk with a given bit rate to the next chunk with another bit rate. This way when the competing traffic on the network introduces variations on the rate at which the A/V content is received, the client terminal is able to react and adapt by selecting chunks with a bit rate that allows maintaining the buffer filling to a secure level. Indeed, the client terminal tries to reach the highest possible bit rate to provide a good viewing quality to end user, while staying at a level where the rendering will not suffer from late reception of data causing macro-blocks or picture freezes.
More particularly, a HAS player is usually made available from a service provider application and can be downloaded by the user. An adaptive streaming player involves the three following key functions:                the chunk request scheduling. Two request strategies are generally implemented. The immediate download used during the initial ramp-up phase to build up the player buffer and the periodic download used in the steady phase to maintain a constant playback buffer. Depending on the players' initial conditions, the periodic download can lead to suboptimal time allocation resulting in unfairness in bandwidth allocation when a HAS stream compete for bandwidth with another stream, as described in “Improving Fairness, Efficiency, and Stability in HTTP-based Adaptive Video Streaming with FESTIVE”, Junchen Jiang and al., CoNext 2012;        the bit rate selection. The basic strategy is to conservatively choose the highest available bit rate lower than the estimated bandwidth. The conservatism of the selection algorithm will be evaluated according to the margin taken between the value of the estimated bandwidth and the value of the maximum requested bit rate allowed. The conservative value may be expressed in percentage;        the bandwidth estimation. The bandwidth estimation is based on the instantaneous throughput (i.e. the download size divided by the download time). Most commercial players improve the estimation using filtering techniques. The current estimation is then averaged over the last several observations to smooth its dynamic.        
While these HAS techniques have proven to work reasonably well when compared to pre-existing technologies, recent works point out that under some specific challenging circumstances (i.e. competition with another HAS client or with another TCP flow on a bottleneck), HAS implementations can suffer from severe stability, fairness and efficiency issues.
In particular, it has been observed that two HAS clients competing for bandwidth leads to unpredictable results, ultimately jeopardizing the user experience. In addition, HAS terminals show an incapacity to reclaim their fair share of bandwidth when competing with a greedy TCP flow (e.g. bulk transfer) because of their periodic download profile resulting in OFF periods where the bandwidth is not evaluated and then potentially underestimated. And during these OFF periods in particular, the other TCP flow can take the opportunity to grab the bandwidth.
Lastly, during the steady state, HAS client terminals apply a given bandwidth conservatism to maintain a given target rate (e.g. a conservative value of 20%), so that HTTP streaming fails to fill 100% of the provided bandwidth leading to bandwidth underutilization.
Besides, it has been observed by the Applicant that convergence is also an important criterion to evaluate the efficiency and depends on the initial conditions. The time to converge is currently not deterministic and might be long, which results in a poor user experience and potentially a sub optimal bandwidth usage.
The present invention attempts to remedy at least some of the above mentioned concerns in order to, at least, improve the convergence of a streaming content to a defined target rate.